When the Internet was originally devised, hosts were fixed in location and there was implicit trust between users despite the lack of real security or host identification protocols, and this situation continued even upon wider uptake and use of the technology. There was little need to consider techniques for dealing with host mobility since computers were relatively bulky and immobile.
With the revolution in telecommunications and computer industry in the early 1990's, smaller communication equipment and computers became more widely available and the invention of the World Wide Web, and all the services that emerged with it, finally made the Internet attractive for the average person. The combination of increasing usage of the network and mobile telecommunications created the need for secure mobility management in the Internet.
Taking into account the above mobility management, the Mobile IP standard (C. Perkins, “IP Mobility Support for IPv4”, RFC 3220, IETF, 2002) and the Mobile IPv6 standard (D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”, RFC3775, IETF, 2004) have been introduced. Extensions to the Mobile IPv6 standard have also been developed and standardised (e.g. see J. Arkko, C. Vogt, W. Haddad, “Enhanced Route Optimization for Mobile IPv6”, IETF, RFC 4866, May 2007). Together these specifications are planned to provide mobility support for the next generation Internet.
An IP address describes a topological location of a node in the network. The IP address is used to route the packet from the source node to the destination. At the same time, the IP address is generally also used to identify the node, providing two different functions in one entity. This can be considered to be akin to a person responding with their home address when asked who they are. When mobility is also considered, the situation becomes even more complicated: since IP addresses act as host identifiers in this scheme, they must not be changed; however, since IP addresses also describe topological locations, they must necessarily change when a host changes its location in the network.
With Mobile IP, the solution is to use a fixed home location providing a “home address” for the node. The home address both identifies the node and provides a stable location for it when it is at home. The current location information is available in the form of a care-of address, which is used for routing purposes when the node is away from home.
Cellular networks provide roaming capabilities, where visited networks provide connectivity to roaming users. The traffic of roaming users may be tunnelled back to the home network or it may leave or be terminated in the visited network. Possible reasons for using home tunnelling include: the ability to charge at home; enabling policy control at home; having a mobility anchor at home; providing location privacy; and allowing for the possibility that servers providing user service are in the home network. Possible reasons for local breakout include: optimal routing; shorter (and hence cheaper) access to the Internet; and access to services provided locally in the visited network.
The following two mechanisms for providing home tunnelling and optimal routing (local breakout) dynamically while being reachable at the same IP address are known:                IP2, where route optimization is entirely network centric.        The Mobile IP standard, as mentioned above, where Mobile Nodes (MN) themselves send location update messages (Binding Updates, BU) to Correspondent Nodes (CN). Then Correspondent Nodes direct their traffic to the current location of the MN.        
While IP2 allows full control for the network to decide routing (including home tunnelling or route optimization), it is a complex system requiring IP2 to be implemented at the visited and home networks and also in the network of the CN. Its complexity makes it unsuitable for a number of purposes.
Another form of route optimization (albeit a less powerful one) is the use of a locally-assigned IP address for communication by the MN instead of the home address. In this case, no specific mechanisms are needed to ensure direct routing between the CN and the MN; however, the transport session may break if the MN moves away. The MN may choose to initiate communication using a locally-assigned address at its own discretion.
The Mobile IP standard will now be described in more detail with reference to FIGS. 1 and 2 of the accompanying drawings.
Mobile IP is a mechanism for maintaining transparent network connectivity to and from a Mobile Node (MN), such as a mobile terminal or telephone over an IP based network. Mobile IP enables a Mobile Node to be addressed by the IP address it uses in its home network (Home Address), regardless of the network to which it is currently physically attached. Therefore, ongoing network connections to and from a Mobile Node can be maintained even as the Mobile Node is moving from one subnet to the other. Mobile IP can be implemented using IP protocol version 4, IPv4 or IP protocol version 6, IPv6. IPv6 is generally preferred as IPv4 has a number of limitations in a mobile environment. The IPv6 protocol as such is specified in RFC 2460.
In Mobile IPv6, each Mobile Node is always identified by its Home Address. While away from its home IP subnet (Home Subnet) a Mobile Node is also associated with a Care-of Address which indicates the Mobile Node's current location. The association of the Mobile Node's Home Address and the Care-of Address is known as Binding. A router in the Home Subnet, known as the Home Agent, maintains a record of the current Binding of the Mobile Node. The Mobile Node can acquire its Care-of Address through conventional IPv6 mechanisms called auto-configuration at the visited (or foreign) IP subnet.
Any node with which a Mobile Node is communicating is referred to as a Correspondent Node. The Correspondent Node could itself be either mobile or stationary.
There are two possible modes for communications between the Mobile Node and the Correspondent Node. The first mode, bidirectional tunnelling to/from the Home Agent, does not require Mobile IPv6 support from the Correspondent Node and is available even if the Mobile Node has not registered its current Binding with the Correspondent Node. The first mode is illustrated in FIG. 1 of the accompanying drawings. IP packets from the Correspondent Node are routed to the Home Agent and then tunnelled to the Mobile Node. Packets to the Correspondent Node are tunnelled from the Mobile Node to the Home Agent (“reverse tunnelled”) and then routed normally from the Home Network to the Correspondent Node. In this mode, the Home Agent intercepts any IPv6 packets addressed to the Mobile Node's Home Address and each intercepted packet is tunnelled to the Mobile Node's primary Care-of Address. This tunnelling is performed using IPv6 encapsulation.
The second mode, referred to as ‘route optimization’, requires the Mobile Node to register its current binding at the Correspondent Node. The second mode is illustrated in FIG. 2 of the accompanying drawings. Packets from the Correspondent Node can be routed directly to the Care-of Address of the Mobile Node. When sending a packet to an IPv6 destination, the Correspondent Node checks its cached bindings for an entry for the packet's destination address. If a cached binding for this destination address is found, the node uses a new type of IPv6 routing header to route the packet to the Mobile Node by way of the Care-of Address indicated in this binding.
In this regard, a routing header may be present as an IPv6 header extension, and indicates that the payload has to be delivered to a destination socket in some way that is different from what would be carried out by standard receiver host processing. Mobile IPv6 defines a new routing header variant, the type 2 routing header, to allow the packet to be routed directly from a Correspondent Node to the Mobile Node's care-of address. Use of the term “routing header” typically refers to use of a type 2 routing header. The Mobile Node's care-of address is inserted into the IPv6 Destination Address field. Once the packet arrives at the care-of address, the Mobile Node extracts the final destination address (equal to its home address) from the routing header, and delivers the packet to the appropriate socket as if the packet were addressed to the extracted address.
The new routing header uses a different type than defined for “regular” IPv6 source routing, enabling firewalls to apply different rules to source routed packets than to Mobile IPv6. This routing header type (type 2) is restricted to carry only one IPv6 address and can only be processed by the final destination and not intermediate routers.
All IPv6 nodes which process this routing header must verify that the address contained within is the node's own home address in order to prevent packets from being forwarded outside the node. The IP address contained in the routing header, since it is the mobile node's home address, must be a unicast routable address.
Furthermore, if the scope of the home address is smaller than the scope of the care-of address, the mobile node must discard the packet.
With route optimization, the Mobile Node registers its current binding at the Correspondent Node using a Binding Update message sent from the Mobile Node to the Correspondent Node (which the Correspondent Node acknowledges with a Binding Update Acknowledgement message). The Binding Update message contains as its destination address the address of the Correspondent Node. The source address of the message is the Care-of Address of the Mobile Node, whilst the home address of the Mobile Node is contained within a home address field of the message header. Route optimisation requires the inclusion of a routing header (a type 2 routing header) in the packet headers, indicating that the packets must be dealt with in a special way.
In order to enhance security of the Optimised Routing process, a “proof-of-address” mechanism may be employed. One such mechanism requires that, prior to issuing a (first) Binding Update message, a roaming Mobile Node send to a Correspondent Node a first message (HoTI) to the Correspondent Node employing route optimisation and a second message (CoTI) not employing route optimisation. The second message travels via the Home Agent whilst the first does not. The Correspondent Node replies to the first message with a first part of a random number generated by the Correspondent Node, and replies to the second message with a second part of the random number. The Mobile Node will only receive both parts of the random number if it has given both a valid Care-of Address and a valid Home Address. When the Binding Update is subsequently sent to the Correspondent Node, the Mobile Node includes both parts of the random number in the message to prove ownership of the Care-of and Home Addresses.
Once implemented, Route Optimisation allows the Mobile Node to send packets directly to the Correspondent Node. The Care-of Address is included as the source address in these “outgoing” packets. This is done by the Mobile IP protocol layer at the Mobile Node, which replaces the home address with the Care-of Address as the source address in outgoing packets. The Home Address is included in a further header field. The Mobile IP protocol layer at the Correspondent Node screens incoming mails by comparing the source addresses of the packets with Care-of Addresses held in its binding cache. If a match is found, the Care-of Address is replaced with the corresponding Home address, in the source address field, before passing the message to higher layers. Transit through the home network is thus avoided.
Considering the reverse direction, packets from the Correspondent Node can be routed directly to the Care-of Address of the Mobile Node. When sending a packet to an IPv6 destination, the Correspondent Node checks its cached bindings for an entry for the packet's destination address. If a cached binding for this destination address is found, the node substitutes the destination address for the corresponding Care-of Address, whilst including the destination address (i.e. the Home address) in a further header field. Upon receipt of a packet at the Mobile Node, the Mobile IP protocol layer replaces the Care-of Address in the destination field with the home address of the Mobile Node. The packet is then passed to higher protocol layers. Again, transit through the home network is avoided.
Routing packets directly to the Mobile Node's Care-of Address with ‘route optimization’ allows the shortest communications path to be used. It also eliminates congestion at the Mobile Node's Home Agent. In addition, the impact of any possible failure of the Home Agent or networks on the path to or from it is reduced. However, the possibility of ‘route optimization’ that MIPv6 provides does lead to a terminal centric solution, as the establishment of home address to care-of address bindings in the correspondent node is decided, initiated and executed by the mobile node itself. This does not allow network operators to influence whether traffic is tunnelled home or routed locally. For example, home networks have no influence if a particular piece of traffic is route via them or not. This is true even if the visited network fully co-operates with the home network in this regard. The simple use of a local IP address is also decided by the terminal. If (home) network control of route optimization is requested, the use of local addresses needs to be controlled too.
The design of Mobile IPv6 did not include performing a care-of address (CoA) reachability test each time the mobile node (MN) updates its home agent (HA) with a new CoA. One possible reason for leaving such a test out of the specification is that with MIPv6 the focus is more on the route optimization (RO) mode, which involves performing a return routability (RR) procedure every seven minutes as long as the MN is located in a foreign network (while having ongoing session(s)). However, the RR procedure alone consists of exchanging four signalling messages (namely, HoTI/HoT and CoTI/CoT) between the MN and each CN. The RR procedure is followed by sending a binding update (BU) message to each CN to update it with the new MN's CoA (and probably receiving a binding acknowledgment (BA)). It follows that updating two CNs with the new CoA requires the MN to exchange at least ten mobility signalling messages after having updated its own HA with the new CoA, which in turn requires exchanging a BU/BA messages. In total, 12 signalling messages are needed before resuming the data packets exchange. After that, the MN needs to repeat the RR with each CN every 7 minutes.
While the CoA reachability test is mandatory in the RO mode, it has been neglected when it comes to updating the HA. One reason advanced for this is that, in case of an attack, the HA will get a call (from someone or discover it by itself) and punish the attacker. Another reason could be considered to be avoiding increasing the burden of signalling messages on the MN, which is already burdened with the main task of actually exchanging data packets.
On the other side, performing the same CoA reachability test on the HA side, prior to updating it with the new CoA, requires two additional mobility signalling. However, in order to be efficient, the CoA test must be repeated periodically as is the case with each CN. Otherwise a multi-homed MN can perform a successful CoA reachability test then update its HA with its new CoA then use another interface to launch a network flooding attack against the foreign network. In summary, this means a significant increase of signalling messages on the MN side. In order to avoid such scenario, it has been decided that the MN does not need a CoA reachability test when updating the HA.
In order to cut the number of signalling messages, the enhanced mobile IPv6 RO mode (see J. Arkko, C. Vogt, W. Haddad, “Enhanced Route Optimization for Mobile IPv6”, IETF, RFC 4866, May 2007) has been designed and standardized. EMIPv6 relies on the cryptographically generated address (see T. Aura, “Cryptographically Generated Addresses”, IETF, RFC 3972, March 2005) to bootstrap a long lifetime bidirectional security association (BSA) between the MN and the CN instead of relying on routing properties to establish a temporary BSA as is the case in MIPv6 protocol. Consequently, EMIPv6 succeeds in substituting the RR with a CGA technique but at the expense of abandoning the protection against network flooding attack. In order to counter such threat without re-introducing the periodic RR, a defence mechanism based on establishing a cryptographic relationship (also know as a ‘symbiotic’ relationship) between the MN and the access router (AR) in the visited network has been recently introduced in W. Haddad, M. Naslund, “Using ‘Symbiotic’ Relationship to Repel Network Flooding Attack”, IETF, draft-haddad-mipshop-netflood-defense-00, December 2007; this will be referred to herein as the “NFD” protocol (Network Flooding Defence).
The NFD protocol enables the visited network to repel a network flooding attack, which can be launched via using the RO mode. However, it does not provide any protection to the visited network in case the attack is launched via using the bidirectional tunneling (BT) mode where all data packets exchanged between the MN and the CN(s) are tunneled via the MN's HA. Furthermore, as the main goal in EMIPv6 was to cut the number of mobility signalling messages on the MN side as much as possible, it is not appropriate to clone a CoTI/CoT exchange between the MN and the HA prior to sending a BU message. In fact, doing that will make EMIPv6 no different than MIPv6 RO mode in case the MN is exchanging data packets with the CN and is constantly on the move. Note that the situation may become further aggravated when the MN is registering multiple CoAs with its HA.
It is desirable to address the above-mentioned issues concerning the existing approaches.